home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15165 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: newsfeed.internetmci.com!xmission!news
  2. From: macron@xmission.com (Joe Schlimgen)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: auto_ptr capability question
  5. Date: Wed, 03 Apr 1996 23:42:24 GMT
  6. Organization: XMission Internet (801 539 0900)
  7. Message-ID: <31630583.85660528@news.xmission.com>
  8. References: <31600aa3.1288774@news.xmission.com>
  9. NNTP-Posting-Host: slc138.xmission.com
  10. X-Newsreader: Forte Agent .99d/32.182
  11.  
  12. On Mon, 01 Apr 1996 17:17:51 GMT (or thereabouts), willer@carolian.com
  13. (Steve Willer) wrote:
  14.  
  15. [On my saying auto_ptr was part of the STL:]
  16.  
  17. >First of all, auto_ptr is not part of the STL. It's part of the
  18. >standard C++ library. The "STL" encompasses the containers like list
  19. >and vector, iterators, and algorithms such as sort() and transform().
  20.  
  21. True, but a minor detail that has nothing to do with the problem...
  22.  
  23.  
  24. [On an implicit conversion from auto_ptr<T> to T*:]
  25.  
  26. >Now, as for explicit versus implicit...it's for the same reason that
  27. >std::string doesn't have an implicit conversion to "const char *":
  28. >It's dangerous, and bugs can creep in undetected. I'm perfectly happy
  29. >having to type a few more characters in order to avoid subtle bugs in
  30. >my code. For a detailed explanation, check Meyers's "More Effective
  31. >C++" book, item #5.
  32.  
  33. I agree that a few extra keystrokes that avoid possible problems are
  34. well worth it. I've also been using my auto_ptr-like class and a string
  35. class that have implicit conversions with no problems (unless they're
  36. **very** subtle). Mostly, the implicit conversions have been used for
  37. parameters to older functions. Can you give any examples of the type of
  38. problems you're talking about?
  39.  
  40. Thanks for the book reference, I'll check it out.
  41.  
  42.  
  43. [On the memory leak following assignment to an auto_ptr:]
  44.  
  45. >Ownership is being _transferred_. Note that if you have something
  46. >like:
  47. >
  48. >auto_ptr<T> a;
  49. >auto_ptr<T> b(new T);
  50. >a = b;
  51. >
  52. >What this means is that at the second line, "b" owns a T, and "a" owns
  53. >nothing. When you say "a=b", "a" now owns the T and "b" owns nothing.
  54. >At the third line, no new T's are created -- the one T that got
  55. >explicitly created is simply passed around.
  56.  
  57. I've always understood the transfer of ownership. Let me change your
  58. example just a bit to show the problem I'm talking about:
  59.  
  60. auto_ptr<T> a(new T);        // Given 'a' something to manage
  61. auto_ptr<T> b(new T);
  62. a = b;
  63.  
  64. In line 1, 'a' is given the responsibility of managing a pointer to a
  65. 'T'. In line 3, 'b' is told to release it's ownership and transfer
  66. responsibility to 'a'. 'a' does *nothing* with the object it *was*
  67. managing and a leak occurs. In fact, the *only* way the object gets
  68. deleted is when the destructor is called. To fix this one must do the
  69. following:
  70.  
  71. auto_ptr<T> a(new T);
  72. auto_ptr<T> b(new T);
  73. delete a.release();                // Delete the old T before getting new one
  74. a = b;
  75.  
  76. (Talk about subtle bugs...) This places the responsibility of deleting
  77. the previous object on the programmer. And you know how responsible we
  78. are. :)
  79.  
  80.  
  81.  
  82. -- The Truth Is Out There --
  83.